We use the following color map to get a partially filtering, red dust for example:

Some of the most common problems and pitfalls are described below to help us avoid the most common problems.

What's wrong with this example? It's simply that a halo is used to describe the interior of an object and that one cannot describe this interior by describing how the surface of the object looks like. But that's what was done in the example above. We cannot imagine what the interior of the sphere will look like. Will it be filled completey with the halo? Will there be areas filled by the halo and some filled by air? How will those areas look like?

We won't be able to tell the interior's properties from looking at the surface. It's just not possible. This should always be kept in mind.

If the above example was meant to create a sphere filled with a halo and covered with a checker board pattern that partially hid the halo we would have used the following syntax:

A halo is always applied to an object in the following way:

There's no halo allowed inside any pigment statement, color map, pigment map, texture map, material map, or whatever. We are not hindered to do this but we will not get what we want.

We can use halos with a layered textures as long as we make sure that the halos are only attached to the lowest layer (this layer has to be partially transparent to see the halo of course).

Scaling the object before the halo statement will only scale the container object not the halo. This is useful if we want to avoid that the surface of the container object becomes visible due to the use of turbulence. As we have learned in the sections above particles may move out of the container object - where they are invisible - if turbulence is added. This only works for spherical and box mapping because the density fields described by the other mapping types don't have finite dimensions.

If the scale keyword is used after the halo statement both, the halo and the container object, are scaled. This is useful to scale the halo to our needs.

The halo keeps its appearance regardless of the transformations applied to the container object (after the halo), i.e. the halo's translucency, color and turbulence characteristics will not change.

The halo's appearance is independent from the sampling rate as long as there are enough samples to get a good estimate of what the halo really looks like. This means that one or two samples are hardly ever enough to determine the halo's appearance. As we increase the number of samples the halo will quickly approach its real appearance.

To put it in a nutshell, the halo will not change its appearance with the sample rate as long as we have a sufficient number of samples and no aliasing artifacts occur.

Whenever we add turbulence to a halo we must not use the constant density function.

In order to experiment with some of the exciting new texturing options, let us set up a basic scene file, into which we will be plugging the example textures to experiment with later. So to begin, we set up the following basic include files, a camera and a light source.

Okay, what we have done here is very simple, and probably quite recognizable if we have been working with color maps all along anyway. All we have done is substituted a pigment map where a color map would normally go, and as the entries in our map, we have referenced our declared pigments. When we render this example, we see a pattern which fades back and forth between the classic checkerboard, and those colorful rings. Because we fade from Pigment1 to Pigment2 and then back again, we see a clear blending of the two patterns at the transition points. We could just as easily get a sudden transition by amending the map to read.

Blending individual pigment patterns is just the beginning.

First of all, we have chosen a solid white color to show off all bumping to best effect. Secondly, we notice that our map blends smoothly from all bumps at 0.0 to all ripples at 1.0, but because this is a default gradient, it falls off abruptly back to bumps at the beginning of the next cycle. We Render this and see just enough sharp transitions to clearly see where one normal gives over to another, yet also an example of how two normal patterns look while they are smoothly blending into one another.

The syntax is the same as we would expect. We just changed the type of map, moved it into the normal block and supplied appropriate bump types. It is important to remember that as of POV-Ray 3, all patterns that work with pigments work as normals as well (and vice versa, of course) so we could just as easily have blended from wood to granite, or any other pattern we like. We experiment a bit and get a feel for what the different patterns look like.

After seeing how interesting the various normals look blended, we might like to see them completely blended all the way through rather than this business of fading from one to the next. Well, that is possible too, but we would be getting ahead of ourselves. That is called the average function, and we will return to it a little bit further down the page.

Now, what have we done here? The background plane alternates vertically between two textures, identical except for their finishes. When we render this, the cylinder has a reflection part of the way down the plane, and then stops reflecting, then begins and then stops again, in a gradient pattern down the surface of the plane. With a little adaptation, this could be used with any pattern, and in any number of creative ways, whether we just wanted to give various parts of an object different finishes, as we are doing here, or whole different textures altogether.

One might ask: if there is a texture map, why do we need pigment and normal maps? Fair question. The answer: speed of calculation. If we use a texture map, for every in-between point, POV-Ray must make multiple calculations for each texture element, and then run a weighted average to produce the correct value for that point. Using just a pigment map (or just a normal map) decreases the overall number of calculations, and our texture renders a bit faster in the bargain. As a rule of thumb: we use pigment or normal maps where we can and only fall back on texture maps if we need the extra flexibility.

Naturally they also work with whole pigments, normals, and entire textures, just as the other patterns do above. The only difference is that we list entries in the pattern (as we would do with individual colors) rather than using a map of entries. Here is an example. We strike the plane and any declared pigments we had left over in our last example, and add the following to our basic file.

We begin by declaring an example of each of the color list patterns as individual pigments. Then we use the hexagon pattern as a pigment list pattern, simply feeding it a list of pigments rather than colors as we did above. There are two rotate statements throughout this example, because bricks are aligned along the z-direction, while hexagons align along the y-direction, and we wanted everything to face toward the camera we originally declared out in the -z-direction so we can really see the patterns within patterns effect here.

Of course color list patterns used to be only for pigments, but as of POV-Ray 3, everything that worked for pigments can now also be adapted for normals or entire textures. A couple of quick examples might look like

or...